Skip to content

api: expose root Stats::Scope via Api::Api#6712

Merged
mattklein123 merged 17 commits intoenvoyproxy:masterfrom
ahedberg:expose_root_scope
May 16, 2019
Merged

api: expose root Stats::Scope via Api::Api#6712
mattklein123 merged 17 commits intoenvoyproxy:masterfrom
ahedberg:expose_root_scope

Conversation

@ahedberg
Copy link
Contributor

Description: Add rootScope() to Api::Api so stats can be read by filters, etc. without making an admin request.
Risk Level: Low
Testing: bazel test //test/...
Docs Changes: N/A
Release Notes: N/A (but happy to add if warranted)
Fixes #6706

Signed-off-by: Ashley Hedberg <ahedberg@google.com>
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
This reverts commit 2728a65.

Signed-off-by: Ashley Hedberg <ahedberg@google.com>
@mattklein123 mattklein123 self-assigned this Apr 26, 2019
Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, LGTM. Is it possible to add a test somewhere that actually uses this in a similar way to what you are going to do in your private filter? We have integration test filters now so it might be easy enough to do there. Thank you!

/wait

ahedberg added 2 commits May 2, 2019 09:20
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
@ahedberg
Copy link
Contributor Author

ahedberg commented May 2, 2019

Still working on tests, but wanted to throw up the APIs for early feedback.

@mattklein123
Copy link
Member

Still working on tests, but wanted to throw up the APIs for early feedback.

Looks great, thank you.

/wait

eds_ready_filter.cc)

Signed-off-by: Ashley Hedberg <ahedberg@google.com>
@ahedberg ahedberg changed the title api: expose root Stats::Scope via Api::Api [WIP] api: expose root Stats::Scope via Api::Api May 9, 2019
it through the rootScope.

Signed-off-by: Ashley Hedberg <ahedberg@google.com>
@ahedberg
Copy link
Contributor Author

ahedberg commented May 9, 2019

@jmarantz - any idea why the new eds_ready_filter can't find the stat in the root scope? Some very hacky debug logging suggests that the "cluster.cluster_0.membership_healthy" stat is added to scopes whose parent is the root scope, but querying the root scope for that stat returns nothing.

@jmarantz jmarantz self-assigned this May 10, 2019
ahedberg added 2 commits May 13, 2019 11:39
find*

Signed-off-by: Ashley Hedberg <ahedberg@google.com>
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
ahedberg added 3 commits May 14, 2019 11:29
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
@ahedberg
Copy link
Contributor Author

We have an integration test!

I think the main outstanding questions here are:

  • How to handle prefixes
    • Folks querying the root scope will (presumably) specify a fully-qualified name, and don't want prefixes appended.
    • Folks querying child scopes might expect that the prefix will be added.
  • How to handle lookups when there are overlapping scopes

Copy link
Contributor

@jmarantz jmarantz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks basically ready to go; just one simplification comment and a nit or two.

}

std::shared_ptr<StatType>* central_ref = &(iter->second);
if (tls_cache) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you indicated 'done' in the comment I made earlier suggesting we not bother with the tls cache, since you are holding a lock anyway. I see you are no longer reading from it, but I'm not sure that usage of the 'find' method is a good signal that we should populate the current thread's cache. In particular -- not really fully understanding the application -- I was wondering if this might tend to be run from the main thread, whose tls cache will (I believe) be consulted approximately never. @mattklein123 & @fredlas for opinions on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see--I think I misunderstood a previous conversation that we should populate the tls cache upon reading. I don't feel strongly either way.

We're planning on calling this from a filter, similar to eds_ready_filter.cc, if that changes anyone else's opinions.

Signed-off-by: Ashley Hedberg <ahedberg@google.com>
@ahedberg ahedberg changed the title [WIP] api: expose root Stats::Scope via Api::Api api: expose root Stats::Scope via Api::Api May 15, 2019
Signed-off-by: Ashley Hedberg <ahedberg@google.com>
jmarantz
jmarantz previously approved these changes May 15, 2019
Copy link
Contributor

@jmarantz jmarantz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ahedberg -- looks great. I am in favor of this simpler approach since you are holding the lock anyway, the tls cache doesn't add value for this flow.

And the confusion you had earlier was my fault -- I had mistakenly suggested you populate the tls cache because I did not realize you had to hold the lock anyway to loop over scopes_.

Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks looks awesome. 1 question and comment.

/wait

Signed-off-by: Ashley Hedberg <ahedberg@google.com>
jmarantz
jmarantz previously approved these changes May 15, 2019
mattklein123
mattklein123 previously approved these changes May 16, 2019
Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@mattklein123
Copy link
Member

@ahedberg I'm pretty confused about how the OSX build is failing and not the others, but the failure looks legit. Can you take a look?

/wait-any

Signed-off-by: Ashley Hedberg <ahedberg@google.com>
@ahedberg ahedberg dismissed stale reviews from mattklein123 and jmarantz via e369e30 May 16, 2019 13:39
@ahedberg
Copy link
Contributor Author

Switched to the version of sendLocalReply accepting response details, both because it's not deprecated and because MacOS doesn't seem to realize the other one exists. ¯_(ツ)_/¯

Signed-off-by: Ashley Hedberg <ahedberg@google.com>
Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect that Azure pipelines is actually merging master before it runs CI which is kind of interesting, and that's why it caught this error. @lizan is that true? Is that expected?

@mattklein123 mattklein123 merged commit 4c80e73 into envoyproxy:master May 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Expose stats store singleton via Api::Api

4 participants